United States 

Johnson et al. 


[19) 


1111 

US005151989A 

[U] Patent Number: 
[45] Date of Patent: 


i f 151 f 989 
. 29, 1992 


[54] DIRECTORY CACHE MANAGEMENT IN A 
DISTRIBUTED DATA PROCESSING 
SYSTEM 

[75] Inventors: Donavon W. Johnson, Georgetown; 

Amal A. Shaheen-Gouda; Todd A. 
Smith, both of Austin, all of Tex. 

[73] Assignee: International Business Machines 
Corporation, Armonk, N.Y. 

[21] Appl. No.: 114,889 

[22] Filed: Feb. 13, 31987 

* N [51] Int. CI. 5 G06F 15/16; G06F 13/00 

[52] US. Q 395/600; 395/200; 

tffc * 364/222.81; 364/222.82; 364/282.3; 364/284.4; 

364/242.94; 364/264; 364/264.5 
[58] Field of Search ... 364/200 MS File. 900 MS File; 

395/200, 600 

[56] References Cited 

U.S. PATENT DOCUMENTS 

4,558,413 12/1985 Schmidt ct al 364/300 

4,698,766 10/1987 Entwistle el al 364/468 

OTHER PUBLICATIONS 

IEEE Proceedings on the 6th International Conference 
on Distributed Computing Systems, Cambridge, 
19th-23rd May 1986, A. B. Sheltzer et a). "Name Ser- 
vice Locality and Cache Design in a Distributed Oper- 
ating System", p. 518, column 1, lines 33-46; column 2, 
lines 1-19; p. 521, column 2, lines 3-39. 
"Sun-3 Architecture", A Sun Technical Report, Aug. 
1986, pp. 8, 9, 49-57. 

Chang, JoMei, "Status Monitor Provides Network 
Locking Services for NFS", 3 pages. 
Chang, JoMei, "SunNet", pp. 71-75. 
Taylor, Bradley; Goldberg, David, "Secure Network- 
ing in the Sun Environment", pp. 28-36. 
IEEE Transactions of Software Engineering, vol. 
SE-12, No. 11, Nov. 1986, A. B. Sheltzer et al, "Inter- 
net Locus: Extending Transparency to an Internet En- 
vironment", p. 1067, column 2, lines 22-44; p. 1071, 
column 2, lines 18-29. 


Hamilton, et al.; "An Administrator's View of Remote 
File Sharing", pp. 1-9. 

Houghton, Tom; "File System Switch", 2 pages. 
Olander, David J., et al., "A Framework for Network- 
ing in System V", pp. 1-8. 

Communications of the ACM, vol. 29, No. 3, Mar. 1986, 
J. H. Morris et al., "Andrew: A Distributed Personal 
Computing Environment", p. 193, column 2, lines 
15-43. 

"Method for General Sharing of Data in Hybrid Mem- 
ory Organization", IBM Technical Disclosure Bulletin, 
vol. 25, No. 5, Oct. 1982, pp. 2606-2620. 
Sandberg et al., "Design and Implementation of the Sun 
Network Filesystem", pp. 119-130. 

(List continued on next page.) 

Primary Examiner— Eddie P. Chan 
Attorney, Agent, or Firm — Douglas H. Lefeve 


[57] 


ABSTRACT 


An improved directory caching technique is provid ed 
for a plurality of data processing systems whicTT are 
co nnected together in a network. I n t he system, when a 
l ocal, or client, data processing system interrogates a 
r emote, or server, data processing system for a unit of 
directory information, the server system is enabled to 
aut omatically send additional units of perti nent director 
mfoTmation back to the client system^rr response to a 
subsequent change in the directory sg u ctufg of th e 
server syste m. If the server system is unable to continue 
Updating the client system, for any of a plurality of 
possible reasons, the server system informs the client 
system of this fact, which enables the client system to 
purge itself of the formerly stored directory cache entry 
relative to this path, since the client system can no 
longer consider this cached path information to be cur- 
rently correct. 
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DIRECTORY PArwr va avup itktt tv a lished by Robcrt J Brady (a Prentice-Hall company) 

DiSSb™ DATA PR^ (1983) ' A m ° rc dcfinitive ^"Ption of communica' 

DISTRIBUTED DATA PROCESSING SYSTEM tions systems for computers, particularly of SNA and 

CROSS REFERENCE TO RELATED < f? LC ' ht ° bC found f in a book b >' R J c yP™ entitled 

APPLICATIONS Communications Architecture for Distributed Systems, 

r • published by Addison-Wesley (1978). It will, however, 

I his application is related in subject matter to the be understood that the invention may be implemented 

following applications filed concurrently herewith and using other and different computers than the IBM RT 

aS US Pat \STM7W g EHh a ™ ^ „ 1 PC interconnected by other networks than the Ethernet 
U.S. Pat. No. 4,897,781 filed by A. Chang, G. H. 10 Ioca] area network or JBM , S §NA 

W^And M^f p "2 \ A J ^ ? r * As me ntioned, the invention to be described hereinaf- 

Node In A Distributed Networking Envfronmem J ?™ rT^ 1 " f" t^T^n ' ^ 

Application Ser. No. 07/014,884, now abandoned, 15 L°« c a n # K A ««wofk potentially may 

filed by D. W. Johnson, L. W. Henson, A. A. Shaheen- a f ces * a " ^ e f ||f & ,n lne nctworit regardless of the nodes 
Gouda. and T. A. Smith for A System Method for ?. Whlch the f,les may reside * As shown in FIG - V * 
Version Level Negotiation. distributed network environment 1 may consist of two 

U.S. Pat. No. 4,887,204 filed by D. W. Johnson, G. H. or more nodes A ' B and c connected through a commu- 
Neuman, C. H. Sauer, A. A. Shaheen-Gouda, and T. A. 20 n,catl0n hnk ° r network 3. The network 3 can be a local 
Smith for A System And Method For Accessing Re- arca netw <>rk (LAN) as mentioned or a wide area net- 
mote Files In A Distributed Networking Environment. work ( W AN). the latter comprising a switched or 

Application Ser. No. 07/014,900, now abandoned, leased teleprocessing (TP) connection to other nodes or 
filed by D. W. Johnson, A. A. Shaheen-Gouda, T. A. t0 a SNA network of systems. At any of the nodes A, B 
Smith for Distributed File Access Structure Lock. 25 or c *nere may be a processing system 10A, 10B or 10C, 

Application Ser. No. 07/014,891, now abandoned, such as the aforementioned IBM RT PC. Each of these 
filed by L. W. Henson, A. A. Shaheen-Gouda, and T. systems 10A, 10B and 10C may be a single user system 
A. Smith for Distributed File and Record Locking. or a multi-user system with the ability to use the net- 

U.S. Pat. No. 5,001,628 filed by D. W. Johnson, L. K. work 3 to access files located at a remote node in the 
Loucks, C. H, Sauer, and T. A. Smith for Single System 30 network. For example, the processing system 10A at 

A ge .• ■ ^ Iocal nodc A is ablc 10 acccss the fllcs SB and 5C at the 

Application Ser. No. 07/014,888, now U.S. Pal. No. remote nodes B and C 

5 1 33,053 filed by D. Johnson, L. K. Loucks, A. A. The problems encountered in accessing remote n odes 

Shaheen-Gouda for Interprocess Communication ca jgelggTunderstood by firsTe"x aminrn g how * STn. 

TnV" ?r?K Pa f CnCy , r 35 febPg-'y?"" accesses fiie77n~T^n^^ 
The disclosures of the foregoing co-pending applica- s^jslTih^ wn m FIG. 2, a local buffer 12 in the 

tions are incorporated herein by reference. o ^e7 atin g system 11 is used ' to buffer ^ "5^^ 

DESCRIPTION fcxred between the per manent storage 2, such as a har d 

TECHNirAi pinn file or a disk in a personal computer, and the user ad. 

ifcCriJNlCALHLLD 40 dre^LjnaceJ!^ 12 in the Turing 

Th*f invcmion general ly relates to imprnvrmrnlt in system llis also referredto'as aTocaT cachrbTT jjael 

operating systems lor a distributcd_d ata pro cessin g sys- buffer. F or more information on thengflh f?P"5^fa^ ng 

IgJLgS ^' "lore P flrtiriilflr] Vl tf7 ftn " improvement 7n an system kernel, see the book by Brian W. Kemighan a nd 

opera^ng SYSlem for a mu ltiprocessor system i ntercon - KOb Pike enti tle d The Unix Programming Environme nt 

nected by a l ocal area neTwork (LANTor a wide area 45 P rentiss-Hall (1984). A more detailedlescription of the 

network (WAN). The improvement according" to the d Esign of the UNIX operating system is to bTfolmd in 

invention provides an increased efficiency in file direc- t he book bv Maurice J. Bac h r Detijn~olThPl1nir /w,. 

tory caching for accessing files by processors in the in* System. Prentiss-Hall ( 1986V Th* l^ fl i7^h7£n 

system, regardless of where those files are located in the bftt understood in ig roofa m m ^7^^^£jt:. 

SyStem 50 data retains the physical characteristics that it had on 

BACKGROUND ART disk; howeve r, the information how resides in a mediu m 

Thic in^«.; rt « ;« . t ii • * i_ j * .. mat lends useil to taster data transfer r ates very close to 

This invention is specifically concerned with distnb- tfi e rates achieved in main c v^m ™„™^, — JL — ~ 

uted data processing systems characterized by a plural- » £enE , rodemark of 

ity of processors interconnected in a network. As actu- 55 AT&T m the u.s.a nnd mher ^mrui. 

ally implemented, the invention runs on a plurality of In the standalone system, the kerne) buffer 12 is iden- 

IBM RT PC'interconnected by IBM's Systems Net- tifi ^ by blocks 15 which are designated as device num- 

work Architecture (SNA), and more specifically SNA ber and logical block number within the device. When 

LU 6.2 Advanced Program to Program Communica- B read system call 16 is issued, it is issued with a file 

tion (APPC). SNA uses as its link level Ethernet*, a 60 descriptor of the file 5 and a byte range within the file 

local area network (LAN) developed by Xerox Corp., 5, as shown in step 101 in FIG. 3. The operating system 

or SDLC (Synchronous Data Link Control). A simpli- H takes this information and converts it to device num- 

fied description of local area networks including the ber and logical block numbers of the device in step 102. 

Ethernet local area network may be found in a book by Then the operating system 11 reads the cache 12 ac- 

'RT and RT PC are registered trademarks of IBM 65 cording to the device number and logical block num- 

Corporation. Ethernet is a trademark of Xerox Corpo- bcrs. step 103. 

ration. Larry E. Jordan and Bruce Churchill entitled Any data read from the disk 2 is kept in the cache 

Communications and Networking for the IBM PC. pub- block 15 until the cache block 15 is needed. Conse- 
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quemly, any successive read requests from an applica- Russel Sanrfhiro « »i -n., „ a i i 

tion program 4 tha. is running on the processing system the S, L \ '' Dei ^ X nd } mplementaUon o{ 

10 for the same data previoSs.y read' from 2 3K ^IW^lS^D^t^.^r^ 

accessed from the cache 12 and not the disk 2 Reading ■ ; , 1 pp ' J ,v t0 I30; Dan Walsh ct al • Over- 
from the cache is iess time c«£fi , TSfS^T ^T*^^^ ? ? " ^ 

the disk; therefore, by reading from the cache oerfor- i u ? 8 .' StatUS Mom,or Prov 'des Network 
mance of the application * fcta^. oS^ ?~ ^ Ch8nS ' " SunNet "> 

the data which is to be accessed is not in the cache then ? ? lu * $ ^ ley TayI ° r ' *' Secure Ne!w °'king 
a disk access must be made, but this requirement occurs u , ? Environment ^ PP- ™ to 36. The AT&T RFS 
infrequently. has also been described in a series of publications inchid- 

Similarly, data written from the application 4 is not * n ^ ew P * Riflcin el al " MRFS Architectural Over, 

saved immediately on the disk 2 but is written to the X ieW ' USENIX Conference Proceedings, Atlanta, Ga. 
cache 12. This again saves time, improving the perfor- * e . 198 ^' pp ' 1 10 ,2 i Richar d Hamilton et al, "An 
mance of the application 4. Modified data blocks in the Administrator's View of Remote File Sharing", pp. 1 to 
cache 12 are saved on the disk 2 periodically under the 15 9; Tom Hou fi ht0n « al., "File Systems Switch", pp. 1 to 
control of the operating system 11. 2 i David J. Olander et al., *'A Framework for Net- 

Use of a cache in a standalone system that utilizes the working in System V'*, pp. 1 to 8. 
A i X t° pCratinS system * which * thc environment in ° ne feature of the distributed services system in 
which the invention was implemented, improves the which the subject invention is implemented which dis- 
overall performance of the system disk and minimizes 2 o tm 6 uisnes " from the Sun Microsystems NFS, for exam- 
access time by eliminating the need for successive read P Ic - IS that s "n's approach was to design what is essen- 
%x£™^ ! ia,,y H a # S, ! tCl T maChinC ' M0fC *P™^y> the server 

In the distributed netwTk ^environment shown in X £^T" ^ '° * 

FIG. 1, there are two ways the process"^ ^system IOC Si ? ' thC f™" d °" n0t St0rc an * informa - 
in local node C could read the file 5A f^ m node A In 25 T cl,cnt " odcs ' lncIud ing such information as 

one way, the processing s^tem ioj col copy tie df.?^ T * ^ ^ ° pen ' Whether 

whole file 5A and then read it as if it werfe a local file 5C , P f ™* * fllc ° pCn in rcad " on| y or rcad - 

residing at node C. Reading the file in this way creates u ^des, or whether a client has locks placed on 
a problem if another processing system 10B at node B r .J"!?* ™ e file. Such an implementation simpli- 
for example, modifies the file 5A after the file 5A has 30 u V SI ? ° SCFVCr because the server does not 
been copied at node C The processing system 10C • u W ' th crr ° r rccovcr y situations which may 
would not have access to the latest modifications to the a " sc % ^ nen a c,, ent foils or goes off-line without prop, 
file 5A. crly informing the server that it is releasing its claim on 

Another way for processing system IOC to access a rc * ources An entirely different approach was 

file 5A at node A is to read one block at a time as the 35 u *? n ,n the dcs, « n of the distributed services system in 
processing system at node C requires it. A problem with W J? thc P rcsenl invention is implemented. More spe- 
this method is that every read has to go across the net- cincally, the distributed services system may be charac- 
work communications link 3 to the node A where the tcrizcd as a "statefull implementation", 
file resides. Sending the data for every successive read . A " s,atefulr server, such as that described here, does 
is time consuming. 40 * ce P information about who is using its files and how 

Accessing files across a network presents two com- lhc f,Ies arc bcin & uscd - Th is requires that the server 
peting problems as illustrated above. One problem in- havc somc wav to detect the loss of contact with a 
volves the time required to transmit data across the client so that accumulated state information about that 
network for successive reads and writes. On the other c ! ,cn * can * discarded. The cache management strate- 
nand, if thc file data is stored in the node to reduce 45 glcs described here, however, cannot be implemented 
network traffic, the file integrity may be lost. For exam- un,css ,he ***** keeps such state information The 
pie, if one of the several nodes is also writing to the file, management of the cache is affected, as described be- 
the other nodes accessing the file may not be accessing Iow ' °y the number of client nodes which have issued 
the latest updated file that has just been written. As requests to open a server file and the read/write modes 
such, the file integrity is lost, and a node may be access- 50 of those opens. 

mg incorrect and outdated files. Within this document, More specifically, because file path name resolution is 
tne term server' will be used to indicate the processing so frequent, it is important that it be done efficientlv 

ystem where the file is permanently stored, and the Ewh system call that uses a file name, for examnle 
UZ k USCd 10 mean any other Passing mount or open, can require that a directory be read and 

.inn Z hT S P I°?l SeS aCC , eSSing the fi,e * Thc inven - 55 $Ciirched for cach com Ponent of the file name's path 

vstem Shff n^-H h ~ ft . er . iS ° f " ° peratinfi ThC pcrformancc P ena "i« of reading numerol £ 
system which provides a solution to the problem of tones each time a file name is used are even more seri 

Ot a h 8 e? fi ^r b H tCd inf0rmali0n ™ in a debuted environment w?e« ^ some of he 

Other approaches to supporting a distributed data directories may be in remote nodes 
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Hirff Sy t ,Cm " ' hal " "P"™^ for marching; (2). .he Possible reasons that the server system can no loneer 

r ' S ?w mem ° ry Wh 'i C A h , C direc,ori « " ccd «° "e continue to send directory path updating informa 'o 

Zt n 7 ^W™'* and ?>• "Che will usually the client system are; (1) a general saturatio^ of «° v r 

have only a limited number of entries to be examined. processing resources. (2) a saturation of the elver's 

hence the most likely to be useful, directory entries. directory caching updating function. (3) the current 

J£ r L£- ,W °- ^ Pr0Wen,S ^ ha ' ,he ° per8,ing ^vailabili«y of a reliable SnfeiVkiV linHS 

system faces in using a directory cache. The contents of tween the server system and the client system (4) the 

he cache must be kept consistent with the contents of necessity of disconnecting th server ^system from h! 

no tT""' a " d ' he ? C h ? mUSt be kept from ge,,i " 8 10 communications ne.wc k.for J^TZ^ZSt 

,S , '^T !"? ,hC he * kept COnsis,ent nance services a « th « ™™ system, and (5) E«e of a 
If the d.rectory cache indicates that a file 1 * inode num. lack of a recent inquiry from the client systetT 

hTJ W bU ' dlrCC ;° ry b u ee " Changed ' per - Whena serversystenS isupdat.^gapShy of clients 
lumber i « ™ c ^»» d ' »** real inode and nears exhaustion of its resources to perform tn 

resolve o £ w^ V,L° T ' " ? T," 15 Upda,i " 8 funC,ion ' ,he server inf °""^ 'he cLnts having 

, ?k ,k 8 [ open could open a file the least recent inquiries, on the basis that those clients' 

different than the one that was specified. If the cache is systems" performances would be least affeaeTby hav- 

allowed to grow arbitrarily, it will eventually be so ing this updating facility suspended V 

ifffcVLrfor e man n ce reqU,red '° ^ " ™" The f ° reg0m8 md 0ther ° b J ects . fea «^es. extensions 

Tr .... a r ■ 20 and advantages of the invention will be apparent from 

responsible 6 ^^ m - t ^^''*^^ following- more particular descriptionof the ™ 

331 fa % " gK ° d,rec,or,cs ' mak,n 8 " ferred embodiments ofthe invention as illustrated in the 

possible for the operating system to purge from the accompanying drawing, 
directory cache any entries that may have changed, 

thus always leaving the directory cache with consistent 25 BRIEF DESCRIPTION OF DRAWING 

entries. When the cache becomes full, some entries can FIG. I is a block diagram showing a typical distrib- 

!%?? n t0 m8 , ke f0f " eW emrie$ ' The Ch0ice 0f u,ed da,a P roce » in 8 which 8 the subject invent 

entries to purge to make room is not critical, but perfor- tion is designed to operate- 

US , U8 " y bC leaS ' T2 aed !f ' hC m0S ' rC " FIG 2 is 8 block dia 6 ram illustrating a typical stand- 

cently used entries are retained. Since the major prob- 30 alone processor system 

£?c,a! d / r ? C '° ry °f Chin8 Ca " b , e hand ' ed in ,his fashion F,a 3 is a lowchart showing the steps performed by 
for stand-alone systems, several stand-alone UNIX TM an operating system when a read system call is ZTc by 
implementations including stand-alone AIX TM do di- an application running on a processor V 
ThZ Ca ^ n,n8 ' ., wl , . FIG. 4 is a block diagram of the data structure illus- 
The solutions available for stand-alone systems do not 35 trating the scenario for following a path to a file open- 
work. n a distributed environment. The directory cache tion at a local node as performed by the operaXyl 
is maintained by client nodes, while changes to directo- tern which supports the subject invention 
nes in other, server, nodes could result in inconsistent FIGS. 5 and 6 are block diagrams of the data struc 
cache entries. Attempts to maintain consistency by tures illustrating the before and after conditions of the 
commun.cat.ng every d.rectory change at every server 40 scenario for a mount file operation at a local node as 
to every client caching directory entries could flood a performed by the operating system- 
network with these messages, vi.iating any performance FIG. 7 is a block diagram, similar' to FIG. 1, showing 

I V , a wn g M T r hC d,reC '°7 CaChi ? B • 8 di5 "ibuted data processing system according to thl 

It would, therefore, provide greatly improved oper- invention- 

at.ng efficiency in accessing file directories in networks 45 FIG. 8 is a block diagram of the data structure for the 

as described above to have the ability to cache file di- distributed file system shown in FIG 7- 

rectory information and be assured of its validity, while FIGS. 9A. 9B, 9C, 9D. 9E and 9F are block diagrams 

no. needlessly and inefficiently updating this informa- of component parts orthe data structure shown in FIG 

tion during periods when no changes have been made. 8; 

SUMMARY OF THE INVENTION 50 FIGS ,0, M and 12 are b,ock diagrams of the data 

.... J . structures illustrating the scenarios for a mount file 
According an improved dire c tory cachin g^tech- operation and following a path to a file at a local and 

nique is provided for a plurality of data pfocessinR sys- remote node in a distributed system as performed by the 

t erns which are connected together in a network. In th e operating system- ' 

S ^^ w - h ^ a J^'xgL£!i£!L t ' dgja processing sj^Tm 55 FIG. 13 shows a typical directory tree structure 

interrogates a remote, or ser ver, dlli processihfl syste m which exists at a local or client system 

for a na i l Of directory information 4 jhj = s|rygrjyjt^is FIG. 14 shows the client directory tree structure of 

enab l ed to automatically send add f npiT^nlis^rplrT i. FIG. 13 and, additionally, a remote, or server, directory 

D_ ent d i recto r yjnformation ba c k l0 lhe c i iem ivMeni m , ree struc , ure which js available for access . . . * 

f esponse to a subsequent change in the directory str uc- 60 system. 

tifre ofthe server system, lithe server system is unlhle FIG. IS shows the contents of a typical directory 

to continue u pdating the cli ent svsiem fnr «nv nf . cache at a client. 

plura ily of possible reasons, the server system inform * FIG. 16 shows the structure of a typical Node Table 

t he client system of this fad, which enables the clien t at a server 

system to purge itsell ofthe fonngrjy = sjgjsd djrect^y 65 FIG. 17 is a flow diagram which shows the opera- 

c i£S. e emry relauve to this parfiTflncelheTIieqt system lions at the server during directory updates in a system 

an no longer consider this cached path information to using the improved directory caching technioue of thk 

be currently correct. invention. 
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FIG. 18 is a detailed flow diagram which shows the 
operation at the client in response to a dfs_fs advise in 
a system using the improved directory caching tech- 
nique of this invention. 

FIG. 19 shows the detailed contents of an entry in the 
directory cache of FIG. 20. 

FIG. 20 shows the hash table technique used in 
searching the contents of the directory cache. 

FIG. 21 is a detailed flow diagram of server opera- 
tions in response to the dfs— lookup rpc request in a 
system using the improved directory caching technique 
of this invention. 

FIG. 22 is a detailed flow diagram of the client opera- 
tions during a lookup of a file name in a remote direc- 
tory in a system using the improved directory caching 
technique of this invention. 

FIG. 23 is a detailed flow diagram of the directory 
cache search operation of this invention. 

BEST MODE FOR CARRYING OUT THE 
INVENTION 

The following disclosure describes solutions to prob- 
lems which are encountered when creating a distributed 
file system in which the logic that manages a machine's 
files is altered to allow files that physically reside in 
several different machines to appear to be part of the 
local machine's file system. The implementation de- 
scribed is an extension of the file system of the AIX 
operating system. Reference should be made to the 
above-referenced Technical Reference for more infor- 
mation on this operating system. Specific knowledge of 
the following AIX file system concepts is assumed: tree 
structured file systems; directories; and file system orga- 
nization, including inodes. 

The essential aspects of a file system that are relevant 
to this discussion are listed below: 

a) each file on an individual file system is uniquely 
identified by its inode number 

b) directories are files, and thus a directory can be 
uniquely identified by its inode number. 

Note: In some contexts it is necessary to distinguish 
between files which are directories and files which are 
not directories (e.g., files which simply contain ordinary 
data, or other files types supported by UNIX derivative 
operating systems such as special files or pipes). 

In this disclosure the term "simple file" is used to 
indicate such a non-directory file. Unless otherwise 
indicated the term "fije" may mean either a directory 
file or a simple file, and, of course, the term "director/' 
means a directory file. 

c) a directory contains an array of entries of the fol- 
lowing form: 


8 


files or directories) whose names appear in the direc- 
tory. 

d) by convention, the inode number of the file sys- 
tem's root directory is inode number 2. 
The following discussion describes how traditional 
UNIX operating systems use mounts of entire file sys- 
tems to create file trees, and how paths are followed in 


su^-aJileJUcee^. 


id 


is 


20 


Following the path Vdirl/dir2/file" within a de- 
vice's file system thus involves the following steps: 

1. Read the file identified by ihodc number 2 (the 
device's root directory). 

2. Sear ch th e directory for an entr y with namc=dir l. 

3. S ^tliyfflgffe^ inode number assoc i- 
at ed with dirl (this is the next directory in the path). 


4. S earch the directory for an entry with name=dir2 . 
5- Read the file identified by the inode number associ- 
ated with dir2 (this is the next directory in the path). 
6. S earch the directory for an entry with name = file. 
T'lTie inode number associated WHTh hie in thiTaTrec- 
tory is the inode number of the simple file identified by 
the path "/dirl/dir2/qk^. 


25 


30 


35 


40 


45 


50 


name-mode number 

where the inode number may be that of a simple file 55 
or that of another directory. 
Note: A directory may contain other directories, 
which, in lurn, may contain other directories or simple 
files. 

Thus a directory may be viewed as the root of a 60 
subtree which may include many levels of descendant 
directories, with the leaves of the tree being "simple 
files". 

In this disclosure the term "descendants" means all of 


The file trees which reside on individual file systems 
are the building blocks from which a node's aggregate 
file tree is built. A particular device (e.g., hard file parti- 
tion) is designated as the device which contains a node's 
root file system. The file tree which resides on another 
device can be added to the node's file tree by perform- 
ing a mount operation. The two principal parameters to 
the mount operation are (I) the name of the device 
which holds the file tree to be mounted and (2) the path 
to the directory upon which the device's file tree is to be 
mounted. This directory must already be part of the 
node's file tree; i.e., it must be a directory in the root file 
system, or it must be a directory in a file system which 
has already been added (via a mount operation) to the 
node's file tree. 

After the mount has been accomplished, paths which 
would ordinarily flow through the "mounted over" 
directory instead flow through the root inode of the 
mounted file system. A mount operation proceeds as 
follows: 

1. Follow the path to the mount point and get the 
inode number and device number of the directory 
which is to be covered by the mounted device. 

2. Create a data structure which contains essentially 
the following: 

a) the device name and inode number of the covered 
directory; and 

b) the device name of the mounted device. 

The path following in the node's aggregate file tree 
consists of (a) following the path in a device file tree 
until encountering an inode which has been mounted 
over (or, of course, the end of the path); (b) once a 
mount point is encountered, using the mount data struc- 
ture to determine which device is next in the path; and 
(c) begin following the path at inode 2 (the root inode) 
in the device indicated in the mount structure. 

The mount data structures are volatile; they are not 
recorded on disk. The list of desired mounts must be 
re-issued each time the machine is powered up as part of 
the Initial Program Load (IPL). The preceding discus- 
sion describes how traditional UNIX operating systems 


~7 ~ 7 „.w M .wt».. w. wv*w 1W l.j uw»» iiauiuuiiai vntA UptlUWJlg SVSiemS 

the files which exist m the file tree below a particular 65 use mounts of entire file systems to create file trees and 


directory, even those which can be reached only by 
going through other directories. The "immediate de- 
scendants" of a directory are only those files (simple 


how paths are followed in such a file tree. Such an 
implementation is restricted to mounting the entire file 
system which resides on a device. The virtual file sys- 
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tern concept described herein and in the reference mate- 
rial allows (1) mounting a portion of the file system 
which resides on a device by allowing the mounting of 
files (directories or simple files) in addition to allowing 
mounting of devices, and (2) mounting either remote or 
local directories over directories which are already part 
of the file tree. The invention described herein is an 
enhancement to the virtual file system concept which 
further allows the mounting of simple files (remote or 
local) over simple files which are already part of the file 
tree. 

In the virtual file system, the operations which are 
performed on a particular device file system are clearly 
separated from those operations which deal with con- 
structing and using the node's aggregate file tree. A 
node's virtual file system allows access to both local and 
remote files. 

The management of local files is a simpler problem 
than management of remote files. For this reason, the 
discussion of the virtual file system is broken into two 20 
parts. The first part describes only local operations. 
This part provides a base from which to discuss remote 
operations. The same data structures and operations are 
used for both remote and local operations. The discus 


10 


separate file access structure for each node which has 
the file open. This state information enables the server 
tojcnfl w h n ui p no h client i s us i ng tho server fi le^. 


10 


15 


le file system supports a set of operations which 
may be performed on it. A process interacts with a file 
system by performing a file system operation as follows: 

1. The user calls one of the operations providing 
(perhaps) some input parameters. 

2. The file system logic performs the operation, 
which may alter the internal data state of the file 

3. The file system logic returns, to the calling user, 
perhaps returning some return parameters. 

The operations which can be performed on a file 
system are referred to as "vn_operations*' or 
"vn-ops". There are several vn— ops, but the ones 
which are important to this discussion are described 
below: 

VN-LOOKUP 

In the vn— lookup operation, the essential iterative 
step in following a path in a file system is to locate the 
name of a path component in a directory and use the 
associated inode number to locate the next file in the 


*™ i« i j L i_ - chain. The pseudo code for the vn_lookup operation on 

sion on local operations describes those aspects of the 25 a Iocal fiJe ^ hstcd be|ow: F 

data and procedures which are relevant to standalone 

operations. The discussion on remote operations adds 

information pertinent to remote operations without, 

however, reiterating what was discussed in the local 

operations section. 30 

FIG. 4 shows the relationship that exists among the 
data structures of the virtual file system. Every mount 
operation creates a new virtual file system (vfs) data 
structure. The essential elements in this structure are (a) 
a pointer to the root vnode (virtual node) of this virtual 35 
file system (e.g., the arrow from block 21 to block 23), 
and (b) a pointer to the vnode which was mounted over 
when this virtual file system was created (e.g., the 
arrow from block 25 to block 24). 

Whenever an inode needs to be represented in the file 40 
system independent portion of the system, it is repre- 
sented by a vnode. The essential elements in this struc- . 
ture are the following: 

a) a pointer to the vfs which contains the vnode (e.g.. 
the arrow from block 22 to block 21); 45- 

b) a pointer to the vfs which is mounted over this 
inode (e.g., the arrow from block 24 to block 25); 
but note however that not all vnodes are the mount 
point for a virtual file system, i.e., a null pointer 
indicates that this vnode is not a mount point; 50 

c) a pointer to either a surrogate inode or a real inode 
(e.g., the arrow from block 26 to block 32); and 


function lookup 

input: directory vnode pointer, 

name lo be looked up in directory 
output: vnode pointer to named filc/dir. 
convert directory vnode pointer 
to an inode pointer: 
- use pointer in vnode 
lock directory i. inode; 
if( we don't have search pcrmmion.in 
directory ) 
unlock directory inode: 
return error; 
search directory for name: 
tf( found ) 

create file handle for name: 
- use inode found in directory entry; 
get pointer to vnode for file handle: 
unlock directory inode: 
return pointer to vnode; 
else - not found 

unlock directory inode; 
return error: 


d) a pointer to a node table entry (this is a non-nu ll 

only when the file is a remote file) . 
The A IX operating system, in common with o ther 55 
U NIX operating systems, keeps a memory resid ent 
table whi ch con tains in formation abouj each inode~tha t 
Js being used by the^systeg L Pot i nstance^ when a file is 
"opened, its" in ode is read from the d isk an d a subset of 


thi s mode information , toother with som e a^i ^aJ 60 ™™ ca '» e sv " em < e f> 

R ation. ,s stored in 1 inode table. Y heS al 2 $ J "S' to ^2 "ST °^ i 

l«yS« I** entry are I^JIZ 11^^ 
h ead of a file access structure list and (b) informatio n 
J rom the d isk inode, the details of w JiiclLa r e not rol e- 

XanLB5?er 65 

The file access structure records information about 

which nodes hav e the file open, and about the modes 

(^eaa^j»4y-^r^ead_writeyof these opens. There is a function lookuppn 


LOOKUPPN 

The lookuppn operation is the function which fol- 
lows paths. Its input is a path (e.g., , Vdirl/dir2/file , ') ( 
and its return is a pointer to the vnode which represents 
the file. Lookuppn calls vn—lookup to read one direc- 
tory, then it checks to see if the vnode returned by 
vn_Jookup has been mounted over. If the vnode is not 
mounted over, then lookuppn calls vn_ lookup in the 
same file system. If the vnode has been mounted over, 
then lookuppn follows the pointer from the mounted 
over vnode (e.g., block 24 in FIG. 4) to the vfs of the 
mounted file system (e.g., block 25 in FIG. 4). From the 

vnode (e.g., block 
directory and not a 
simple file, issues a new vn_ lookup giving as input the 
vfs's root vnode and the name which constitutes the 
next element in the path. The pseudo code for the loo- 
kuppn function is listed below: 
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input: pathname 

output, pointer 10 vnode for named file 
if( firu character of path is '/' ) 
current vnode Tor search is u«r'i root 
directory vnode: 

eke 

current vnode for search is user** 
current directory vnode; 

repeat 

tfl[ next component of path is '*. . '* ) 
while( current vnode is root of a 
virtual file system ) 
current vnode becomes the vnode that 
the virtual file system is mounted 
over: 

if( there is not mounted over vnode ) 
return( error ): - ". ." past root 
of file system 
use vn_ lookup to look up path component 

in current vnode; 
ifl vn .look up found component ): 
cur rem vnode becomes the vnode 

relumed by vn«Jookup: 
while< current vnode is mounted over ) 
follow current vnode 's pointer to vfs 
structure that represent v the 
mounted virtual Tile system: 
current vnode becomes root vnode of 
the mounted vh; 
else - vn_lookup couldn't file component 
return( error ); .. search failed 
untilf there are no additional path 

components ): 
returnf current vnode ); 


10 


15 


20 


25 


' 30 


The operation will be illustrated by describing the 
scenarios of following a path to a file and mounting a 
directory. First, in following a path to a file, suppose an 
application process issues a system call (e.g., open) for 
file *7u/dcpt54/status". This request is accomplished 
by the operating system in the following manner with 
reference to FIG. 4 (operations which are basically 
unchanged from the UNIX operating system are not 
explained here in any detail). The following assump- 
tions are made: First, the vfs represented by block 21 is 
the root virtual file system. Second, the file 4 7u" is 
represented by vnode block 24 and inode block 31. 
Third, a previous mount operation has mounted a de- 
vice's file system onto the directory "AT. This mount 
created the vfs represented by block 25. Fourth, all of 45 
the directories and files involved are on the same de- 
vice. Fifth, the following directory entries exist in the 
indicated directories: 


35 


40 


then finds the vnode (block 24) in the root vfs (block 21) 
and returns a pointer to the vnode. Lookuppn discovers 
that the returned vnode is mounted over in the parent 
vfs. It follows the "mounted over" pointer from the 
vnode (block 24) to the mounted vfs (block 25). Loo- 
kuppn follows the "root vnode" pointer to the root 
vnode (block 26) of the new vfs (block 25). Lookuppn 
now calls vn_lookup again, this time inputting a pointer 
to the root vnode (block 26) and name "dept54". As 
before, vn_lookup reads the directory, finds the inode 
associated with the name, finds or creates a vnode for 
this inode in the parent vfs (block 25) and returns a 
pointer to this vnode. Lookuppn calls vn-Jookup once 
more inputting the vnode for the just found directory 
and the name "status". Vn_lookup reads the directory, 
finds the inode associated with the name (block 34), 
finds or creates a vnode (block 28) for this inode in the 
parent vfs (block 25) and returns a pointer to this vnode. 
The code. which implements the system call now per- 
forms the requested operation on the file. 

Suppose now that an application process issues a 
"mount" system call to mount the file Vu/gorp" over 
the directory "/u/foo". The following scenario explains 
how this request is accomplished by the operating sys- 
tem (again, operations which are basically unchanged 
from the UNIX operating system are not explained in 
any detail). 

This scenario refers to FIG. 5, which represents ini- 
tial conditions, and FIG. 6, which represents the final 
conditions, with the following assumptions: First, the 
vfs represented by block 41 is the root virtual file sys- 
tem. Second, all of the directories and files involved are 
on the same device. Third, the following directory 
entries exist in the indicated directories: 


DIRECTORY 
INODE NUMBER 

NAME 

INODE NUMBER 

2 

"u" 

IS 

2 

"etc** 

83 

15 

"gorp" 

92 

83 

"foo" 

75 

75 

"filer 

89 


DIRECTORY 



INODE NUMBER 

NAME 

INODE NUMBER 

2 


15 

45 

"dept54" 

71 

71 

"status" 

12 


The code which implements the system call calls 
lookuppn to follow the path. Lookuppn starts at the 
root vnode (block 23) of the root virtual file system 
(block 21) and calls vn-Jookup to look up the name "u" 
in the directory file represented by this vnode. Vn_ . 
lookup finds in the directory that the name "u" is associ- 
ated with inode J5 in block 31. V n _lookup must return 
a pointer to a vnode associated with inode IS. To do this 
it first brings inode 15 into the inode table. Then it 
checks to see if there is already a vnode in the parent vfs 
(the input vnode (block 23) has a pointer to the parent 
vfs) for this vnode. In this case there is. Vn_Jookup 


. The code which implements the mount system call 
performs the following operations. Lookuppn is called 
to follow the path to the file which is to be mounted 
over— Vetc/foo". At the completion of this operation, 
the root vfs (block 41) contains a vnode for "/etc/foo" 
50 (block 44) which has a pointer to the root vfs (block 41) 
and pointer to an inode table entry (block 45) for inode 
75. Lookuppn is called to follow a path to the file which 
is to be mounted— "/etc/gorp". At the completion of 
this operation, the root vfs (block 41) contains a vnode 
55 for Vetc/gorp" (block 49) which has a pointer to the 
root vfs (block 41) and a pointer to an inode table entry 
(block 48) for inode 92. Now the mount logic creates 
the new virtual file system by first creating a new vfs 
(block 46) and then creating a root vnode for this vfs 
60 (block 47) with a pointer back to its parent vfs (block 
46) and a pointer to the root inode (inode 92. block 48) 
of the vfs. A "mounted over" pointer is installed in the 
covered vnode (block 44) in the root vfs (block 41), and 
a pointer to the vnode upon which it is mounted (block 
65 44) is installed in the new vfs. 

The foregoing illustrates the data structure for stan- 
dalone operation. Reference is now made to FIG. 13 
which shows a distributed system similar to that shown 
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in FIG. 1 in which the operating system which supports TftU fl^yi- it prevented by use of the inode g e Q ergfjrm 

the present invention has been implemented. In the number. The inode generation number is stored on d isk 

following description, the term "server" is used to indi- as a field in the inode. When the server deletes a file, i t 

cate the node where a file is permanently stored, and the i ncrements the inode generation number. If a requ est 

term "client" is used to mean any other node having 5 a rrives at a server, the file handle is broken apart, t he 

processes accessing the file. It is to be understood, how- d evice number and mode number are used to locate t he 

ever, that the term "server" does not mean a dedicated ino de, and then the file handle inode generation numb er 

server as that term is used in some local area network is compared to the models mode generation numb er If 

systems. The distributed services system in which the t hey are different, then the request is rejected. 

invention is implemented is a truly distributed system 10 When a client wants to open a file which resides on a 

supporting a wide variety of applications running at remote server, it uses a network transport mechanism to 

different nodes in the system which may access files establish a connection with the server. Subsequent 

located anywhere in the system. transactions regarding this file (e.g.» read, write, etc.) 

The data structure for the distributed system shown How on this connection. Each node contains a node 

in FIG. 13 is illustrated in FIG. 8, and the component 15 table. A node uses entries in its node table (e.g., block 

parts of that data structure are shown in FIGS. 9A to 70) to record information about existing connections to 

9F. With reference to FIG. 8, a client node may have remote nodes. 

access to files which reside in a remote server node. There are a limited number of operations that one 

Such a client gains access to a servers files by mounting node in the network can request another node to per- 

one of the server's files. In the client node, the data 20 form on its behalf. These operations are called dfs_ops. 

structures created by a remote mount operation com- When a node makes a request of another node, the 

pare to those created by mounting a local entity in the following operations occur: First, the requesting node 

following ways: Just as in the local case, a remote sends a message which specifies which dfs_operation is 

mount creates a vfs in the client node (e.g., block 54). be ing requested and carries the parameters appropriate 

Just as in the local case, use of a file in a virtual file t0 thal request. Next, the receiving node receives the 

system which contains remote files creates a vnode request and performs the specified operation. Finally, 

structure in the client node (e.g., block 57). Just as in the the receiving node sends a message which carries the 

local case, the vnode structure has a pointer to a inode Te P ] y parameters appropriate for the dfs-operation. 

table entry (e.g., block 63). The inode table entry, how- , n Tnere is a dose correlation between the vn_ops that 

ever, docs not contain the inode information from the are issued within a local node to a file system and the 

remote file. Instead, the inode table entry contains a dfs-ops that are issued over the network. A typical 

surrogate inode. This surrogate inode stands for, or operation on a remote file is as follows: First, a local 

represents, the remote inode. kernel issues a v n~op, not knowing whether the file 

In the server node, some data structures are con- 35 bein 8 operated on is remote or local. Second, since the 
structed to allow the server to record state information f,le resides ,n a remote node . the file system implementa- 
about how remote nodes are using its files. More specifi- tlon code sends the corresponding dfs_op to the node 
cally, each server has a "dummy vfs" (e.g., block 71) to wh,cn holds the file Note that if the file had been a 
provide a vfs to hold files open by remote clients. The local n,e » the operation would have been performed, the 
dummy vfs is not a part of the server's file tree. For each 40 relurn parameters would have been returned, and the 
file which is open by a remote node, there is a vnode task wou,d have been complete. Third, the node which 
(e.g., block 74) in the server's dummy vfs. Each file holds the file receives the dfs_operation request and 
which is open by a remote node has an inode table entry requests its local file system to perform the correspond- 
in the server's inode table (e.g., block 85). This inode ,n « vn_operation. The return parameters from this 
table entry is the same as that which exists because a 45 Vn -°P are used 10 construct the return parameters for 
local process at the server has a file open. For example, th * dfs -°P* Fourl h, the requesting node receives the 
block 84, which is in the table because of a remote open, df$ ~°P re P lv from the * erver nodc and uscs ,hc dfs -°P 
has the same structure as block 88, which is in the table return parameters to construct the return parameters to 
because of an operation at the server. the original vn .operation request. 

When a client and server communicate about a server 50 Thc - 0 P c ? l,,on W1 " bc i» ustr *ed by describing the 

file, they need a way to identify the file. This is done of mounting a remote file over a local file and 

with a file handle. Wiejuu^^^ following a path to a file. In the first scenario, suppose 

server to reply with a designation of a p articular file ^ an application process in a client node issues a 

(ST a remote look l^7e^sT>°the file is^ntified Ju l* m °V, nt syst k c,T l cal t0 m0 ^ l 1 a * erve ' ^l^r /uA 

fijf hand l e . When a client request ^carri eTa^r^ ? or P over the local client file /etc/Too \ The follow - 

oTalaTdcular file (e.g., a remote open request), the fi le !!£. $cenano . explains how this request is accomplished. 

is identified by a ft jL £idte The file hand le containjj he J*" , scena "° refers ;° JSL l ?l wh ' ch k "P resenls *e 

followin^ s ^ evice number. inod rmSnbeTTand ™ U ? Whi ° h re P rese T n * s th , e 

KSSZwS^niSS^ ^— — — final condiUon with the fo lowing .assumptions: The vfs 

The needfor a file handl e is illustrated by the follow- 60 £P resenled b V b ock 51 » virtual file system of 

ing scenario. Suppose a client malces a request of a £ e Be ™ S ? e tree ' " d a " the H scrve ' ^ ect ,°" es and 

j . ri u j 1 • 1 m. r . . files involved are on the same device. The following 

server and gets a file handle in reply. Thc client stores . .. . . . - ... . . ,. , 15 

, * *u n u *i c . . . .u entries exist in the indicated directories: 

and remembers the file handle. Some activity at the 

server causes the file to be deleted and the inode slot 

reused for another file. The client makes a request of the 65 directory 

server using the stored file handle. The server receives INODE NUMBER name inode number 

the file handle and performs the operation on the new Scrvci Node 

file. This would bc an unacceptable operation. 2 'V is 
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continued lnis vnode. Lookuppn discovers that the vnode is 

mounted over (the "mounted over" pointer in block 53 
points to block 54). Lookuppn thus follows the 
"mounted over* 1 pointer to the next vfs (block 54) and 
follows its root vnode pointer to the root vnode (block 
55) of the virtual file system. Lookuppn now calls vn_. 
lookup for the next element ("file2'*) of the path giving 
vn_ lookup a pointer to block 55 and the name "file2'\ 
The directory to be searched resides in a remote node 
The code which implements the mount system calls 10 and is identified by the file handle stored in the client 
lookuppn to follow the path to the file which is to be surrogate inode (block 62). Vn_lookup issues a dfs_. 
mounted over— Vetc/foo". At the completion of this lookup to the server which holds the file, sending the 
operation, the root vfs (block 51) contains a vnode for file handle which identifies the directory and the name 
1 Vetc/foo" (block 53) which has a pointer to the root (-filer). which is to be looked up. When the server 
vfs (block 51) and a pointer to an inode table entry »* receives the dfs_lookup, it uses the file handle to iden- 
(block 61) for mode 75. Since the file being mounted tify the directory to be read and issues a vn_lookup to 
resides in a remote node, a dfs_mount request is issued search for the name "filer in this directory. Vn_ 
to the server node, passing the path Vu/gorp" as the lookup reads the directory and discovers that the inode 
path to the object to be mounted Upon receiving the number associated with the name 'Tiler is 67. Vn_ 
^^rnX eS, ;i! r? e T T*' C l" S l0 ° kUP ? n !° Xooku P constructs a vnode and inode in the dummy 
yt/ffnrn" E V° ' ■ Wh "? i- '? mounled - " virtual file system for inode 67 and returns to lookuppn 

^ss^i sn&r> srs r i nt e ; ;° ? is r ode - Dfc -5? ^ u ? v he infoZ - 

"/u/gorp" which has a pointer to the root vfs and ^T^^Z l^i Vr^ 
pointer to an inode table entry for inode 92. The server 25 ™ a fi SS'^ identified by mode 67 It 

uses the information in the inode (device 0, inode 92) to *TT v * 1° C,ien !' " ,he rCply 10 lhe 

construct a file handle for the file "/u/gorp". The ? fs - lo <* u P request and releases the vnode and inode. 

server returns this file handle in the reply to the dfs_. l * th f fif" 1 ' a vn °de (block 55) and surrogate inode 

mount request and then releases the vnode and inode. ^ lo ? k * 3 > are c ! e * ,ed for lhe found file * Since "filer is 
Finally, the client receives the file handle in the reply to 30 the Iasl P lece ofthe P ath » lookuppn returns to its caller 

the dfs_mount request and performs the operations a P 0,nter 10 the found vnode ( block S5 >* The c0 & 

necessary to create the new virtual file system as fol- w ™9 n implements the system call now performs the 

lows: requested operation on the file. 

a) Create a new vfs (block 54). E* 00 server maintains a list of remote nodes that are 

b) Create a root vnode for this vfs (block 55) with a 35 connected to the server in a structure called the Node 
pointer back to its parent vfs (block 54) and a Table. The Node Table contains information about 
pointer to the root inode ofthe vfs (block 62). Since connections to other nodes and information about cli- 
the root inode of this vfs is a remote file, the inode ems caching directory information. Nodes suspected by 
pointed to from the root vnode is a surrogate inode. ,ne serv er to he caching the server's directory entries 
This surrogate inode contains the file handle re- 40 are marked as such in the Node Table. The server do- 
turned by the server in response to the client's esn ^ know for sure that any client is caching directory 
dfs_mount request. entries (for example, a client's cache could have been 

c) Install a "mounted over" pointer in the covered ^^ e0 * Dv another server's entries pushing out all of the 
vnode (block 53) in the root vfs (block 51). first server's entries), but the server is "conservative" 

d) Install in the new vfs (block 54) a pointer to the 45 and believes that any lookup from a request client node 
vnode upon which it is mounted (block 53). results in a cached entry at the client. 

Suppose now that after executing the remote mount Whenever any directory in the server is changed, the 
described above (mount server /u/gorp over client server uses the dfs_fs_advise rpc to inform all clients 
/etc/foo) a client process issues a system call to operate believed to be caching the server's directory entries that 
on the file "/etc/foo/file2". The block numbers in the 50 some directory entry in the server has changed. A 
following scenario refer to FIG. 11, which represents dfs_fs_advise rpc message, indicating that directories 
initial conditions, and FIG. 12, which represents the have changed at the server, is sent to all nodes in the 
system state after the open operation. First, the code Node Table that are indicated to be suspected of cach- 
which implements the system call calls lookuppn to ing directory entries. After sending a dfs-fs— advise to 
follow the path. Lookuppn starts at the root vnode 55 a client node the Node Table entry for the client node is 
(block 52) of the root virtual file system (block 51) and updated to indicate that the client is not caching any of 
calls vn— lookup to look up the name "u M in the direc- the server's directory entries. A client that receives 
tory file represented by this vnode. Vn_lookup finds in such a dfs_fs_advise purges its cache of alt entries for 
the directory that the name * V is associated with inode directories in the server that sent the dfs_fs_advisc. 
15. Vn-lookup constructs a vnode and inode in the root 60 After a dfs_fs_advise is sent to a client by a server, the 
virtual file system for inode 15 and returns to lookuppn server will not send any additional dfs-fs-advise ipes 
a pointer to this vnode. Lookuppn calls vn_Jookup to the client until after the next lookup rpc received by 
again, this time to look up the name "foo" in the direc- the server from that client. Upon receiving a lookup rpc 
tory identified by inode 15, Vn_lookup reads the indi- from a client, the server will mark the Node Table entry 
catcd directory and discovers that the name 'Too" is 65 for the client as caching directory entries. The server's 
associated with inode 75 in block 61. There already Node Table can be of fixed size. When adding a new 
exists tn the root vfs (block 51) a vnode (block 53) for client to a Node Table with no available space, the 
this mode (block 61), so vn_Jookup returns a pointer to "oldest" entry in the table with a connection use count 
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of zero, can be removed by sending a dfs_fs_advise lo used to link all entries into one additional doubly linked 

that client. In this way. only the most recent users of a list called the younger-older list. Doubly linked lists are 

server cache its directory entries. In addition to purging used to make insertion and removal straightforward. To 

its cache upon receiving a dfs_fs_advise, a client will move an entry to the beginning or end of a list it is first 

purge its directory cache or all entries for a server nid S removed from its current position and inserted into the 

whenever it marks the nid's connection as bad or when- list at the beginning or end. Notice that each entry is on 

ever a good connection for the md is removed, since the two lists, some one of the plurality of previous-next lists 

client can no longer be sure of receiving needed dfs_f- and the single younger-older list 

s_advise from that server. HU. 2U shows how these lists ol en tries are orga- 

An entry m the Node Table indicating that a client is 10 nized into a complete directory cache. Even though all 

caching directory entries doesn't represent a use of the 0 f the lists are doubly linked, to keep the figure clear 

connection between the server and the entry's client on j y the forward list pointers are shown. The pointer 

and it doesn « cause the connection use count to be youngest points to the beginning of the younger-older 

incremented. Similarly, a server's directory data in a lis, an(J , he pointer oldest points to the end to the same 

client s cache doesn t cause the corresponding connec- 15 list. A hash table contains pointers to the beginning of 

tion to have us use count incremented. Therefore, the cach of the previous-next lists. 

connection between a client and a server is not held just A hash function is define d that hashes any node id. 

£r,orv I^Xf ^7" * *° J*™'* 6 " direcloTTfihThi aie. and nathj ^ne WTInTK anEdTx 

rectory entnes^ Before dropping a connection with a i nto the hash tabl e. All entries that h ash into the sa me 

use count that has gone to zero a server sends a dfs_f- 20 l ocation in the hash la bile are chainedtoj glhgr it r Z 

«i^n irTh °c! t e „, rjr ( c ; ih f er e i d of :!: e conne r ^^^^^ to j li^i e 

mm if the chent is suspected of caching the server's in the hash table at that locati oTT «=— 

SSl^i"??^ " connec,,on does "' , cause s ? ri - TWe are four distinct operlfions that are necessary 

?or B e, $ abou " , N„,U ZIT^T', ,h ' $erver J u * „ «> *«PPort the directory caching operations of this in* 

f„,f°" ': N0tlCC ^ h l , i he C,,en '. W1 " pu T ,,s " vention: (1) cache invalidation during directory updat- 

£ ST-,' ,d !«° versthe , b l f dconnec «' on I" order to ing at tne servefi (2) markj nodes 8 as cachi V du P ri 

nodes are still able to send and receive RPCs over any 30 i > T^'" 6 mtxm f T ,h f Ca ' he ,n reSponse ,0 

connection that hasn't been used recently-even [f (he Itt^ZZ^I^ V °' 

connection use count is zero -indicates that the com- [ 8 L ure , • C,,e ? a " d ,he ""'J; N °! e ,hat 

munication process remains connected. a " hoU8h ,h,s d,scuss,on f< \ cu$es « » node 5 role »» • 

FIG. 16 illustrates an example of information appear- 5™" Lt'nu? »°"h f b °/ h ' 

ing in a server s Node Table. For each node id appear- 35 "V?* r " e58nd . 8 terver fOT r ot *l er *< therefore, 

ing in the Node Table there is » simple flag indicating 27'^ h ' Ve SUppC>rt for bo,h c,ient and 

that the identified node could be caching directory - X* ° P ; " , s " ■ . ■ ... .. Z • 7 

information (flag is Y) or that the identif.ed node is not un ? P f™°" h < '"validation during directory 

be caching any directory information (flag is N). In this " pda,,n * 81 ,he ' erver ,S P«J>™«» " follows: if entry 
example, node 5 is not caching any directory informa- 40 ,S be,nB rem0ved or renamed 

tion and hence requires no further dfs_fs_advise rpc's 

when directories change at the server, but node 20 is { ' " " 

believed to be caching directory information and should if entry " "> subdirectory and not just & file 

be sent a dfs_fs_ advise if a server's directory has a * , 

subdirectory renamed or deleted. 45 <° r " ch row in ,he Nodc T8b!c 

FIG. IS is a n example of the kind o f data that is sto red if Um row » diem is caching 

>ifiu& jfegctory cflcJie . In this example notice that infe r- ( 

mation about thref dif ferent node^s being cached : ten, { ^-fr-advise to this rowi client; 

nodes with ids 12 , 2 0, and 52. For node 12, there aTelwo , mark ,hc chcn ' " no1 cacl,in6: 

entries with the same name, "hip". This is pqss^ ejbe- 50 ) 

cause this name "bin" occured in t wo difTere ntdiriecto- > 

ri23 i n node B2. T^e ^roa^bc^dij ^torierFRat had Tile * 

h andles of 177 and 123 in this case, perhaps represent ing 

/Birund/usr/bin. two common o^pctonesjn aix'tm Referring now to'FIG. 17, an overview flow diagram 

svsjemsjiej tree elements, node id, directory TQelan- 55 of the operation at the server in performing operations 

q^_aj ^name~togetner lorm the search key that is_ used necessary for the directory caching technique of this 

whpn gparrhinp tfift ^ itectory cache. In order to speje_ d invention is shown. The operation depicted in FIG. 17 

SEsiPircJyng of the directory cache the actuaT^ta is executed each time the contents of a directory are 

structure usTga is more complex. An yof the commonly updated at a server having a portion of its file system 

used methods for structuring informationT brfasi 60 thereof mounted on a client directory, 

s earchinemay be used . TQi emet hod Ulust rated in FIGS At step 200 a test is made to determine if the entry in 

19 and^Duses a h ashTab^e to spee d up the searching o f the server directory is being removed or renamed. If 

!lL^ director y cache not, this operation ends because no information is sent 

Ho. iv illustrates that a directory cache entry will from the server back to the client relative to additional 

use two pairs of link fields in addit ion to the four fields 65 directory contents. At step 200, if an entry in the server 

discussed ab ove: (1) fields pre vious and next that are directory is being removed or renamed, then a test is 

used to link entries into dou bly linked lists called pj evi- made to determine if this server's directory entry is a 

ous -next lists and (2) fields younger and older that a re cachable one, as indicated at step 201. The entry is 
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cachable if it is a subdirectory and is not cachable if it is 
simply a file. If the entry is not cachable, the operation 
ends at this point. 

If the entry is cachable, the operation proceeds to 
step 202 at which point the first row in the Node Table 
(FIG. 16) is addressed. At step 203 the data in this row 
in the Node Table is tested to determine if the client 
associated with this row is caching information relative 
to this server's directory structure. This would be the 
case if the client has accessed any part of the server's 
directory structure. If so, at step 204 a fs_advise mes- 
sage is sent to the client associated with this row which 
advises the client to clear its directory cache informa- 
tion relative to this server. At step 205 the Node Table 
is marked to indicate that this client is no longer caching 
subdirectory information and, at step 206 the Node 
table is checked to determine if more rows exist in the 
Node Table. If not, the operation ends, but if more rows 
exist in the Node Table, at step 207 the next row in the 
Node Table is accessed. The operation then reverts to 
step 203 as described above. If, at step 203 it is found 
that a row's client is not caching, the operation bypasses 
steps 204 and 205 by jumping to step 206 to determine if 
more rows in the Node Table exist. 

It will, therefore, be understood that in this particular 25 
embodiment the client is advised to erase all cached 
directory information relative to a server when any 
directory structure change occurs at that server. Alter- 
native embodiments would include advising the client 
to erase only those cached entries related to the particu- 
lar path that changed or advising the client of the actual 
changes to that path. 

Operation (2), marking nodes as caching directory 
information during lookup requests is performed as 
follows: perform the lookup request, requested by some 
client; if result is a file handle for a directory 


20 


10 


is 


20 


It will, therefore, be understood that in this particular 
embodiment the server simply records a Boolean value 
indicating whether or not the client is believed to be 
caching some directory information. Alternative em- 
bodiments would include recording more specific infor- 
mation about what values the client had been sent and 
hence what values the client could be caching. 

Operation (3), using the directory cache at the client 
during remote lookup operates as follows: 


30 


35 


/* During pathname resolution tome directory it 
always ibe directory in which the search for 
the next pathname component will occur. 
Initially, thjs directory is the root directory 
or the current working directory depending on 
the original path. During pathname resolution 
in lookuppn. the directory where 
s e a rching is to occur is idem i Tied by its vnodt 
p ointer. ' * — " 

V ' 

/• Because this is the procedure for remote lookup, 
the dire ctory to be searched U a remo te 
directory * ~ ~ 

V * 

s earch the directory cache for a matching entry ; 
if entry i s found " 
{ — 

m ove en try to beginning of youne er-older list: 

else 

(' 

p erform remote lookup, using df s_lookup rpc: 
if resuii_oXjJhc_lo okup is cachab le 


{ 


in sert result into dir e ctory- cach e, ajjhe 
beginni ng of the young er -older -list: 


} 


{ 


/* client can cache it V 

find node table entry for client making requesi: 

mark client as caching directory information: 


Referring now to FIG. 21, the detailed flow diagram 45 
of an operation at the server in performing operations 
necessary for the directory caching technique of this 
invention is shown. The operation depicted in FIG. 21 
is executed each time a lookup request is received by a 
node, that will subsequently act as the server. The re- 
quest is received from some other node, acting as a 
client. 

At step 220. the lookup request is performed as it 
would be in the absence of directory caching. At step 
221. before returning any answer to the client request- 
ing the lookup, the results of the lookup are examined. 
If the result of the lookup, a file handle, is something 
that could be cached by the client, a file handle for a 
directory, then execution proceeds to step 222. If the 
result of the lookup is a file handle for an ordinary file, 
then the client will not be caching this result and the 
operation ends. 

If the result is cachable, the operation proceeds at 
step 222 at which point the Node Table entry for the 
client making the request is found. At step 223 this 65 
Node Table entry is updated to indicate that the corre- 
sponding client may now be caching directory informa- 
tion. After step 223 the operation ends. 


Referring now to FIG. 22, the detailed flow diagram 
of an operation at the client in performing operations 
necessary for the directory caching technique of this 
invention is shown. The operation depicted in FIG. 22 
40 is executed each time a client must lookup a name in a 
remote directory. 

At step 230 the directory cache is searched. This step 
is discussed in more detail below. The results of this 
search are tested at step 231. If the results indicate that 
the file handle for the name that was to be looked up in 
the remote directory was found then the operation pro- 
ceeds to step 232. At step 232, the directory cache entry 
found in step 230 is moved to the front of the ymm^r. 
older list. By moving an entry to the beginning of the 
50 list each time it is searched for t thejooosj recently u^ed 
'ejitnes jend to stay in the cac he and the le ast recent ly 
u sed entries are th e ones that are disca rded. Movjn £an 
entry to the beginning Qf the yoUnfter-olderTisTlsea sv 
because the list is doubly linked. After ste p 23^ the 
operation ends. 

If in step 231 it is determined that the search of step 
230 failed, then the operation proceeds at step 233. At 
step 233, the operations necessary to perform a remote 
lookup are performed. At step 234, the results of the 
remote lookup, performed in step 233 are examined. If 
the results are not cachable, that is, the result is a file 
handle for an ordinary file, the operation ends. 
~ If the file handle returned in step 233 is a directory 
file handle, st ep 234 will determine that the f ilr hanHU 
impeachable and th e operation will proceed with ste p 
2 35. At step 235, the entry at the end of the young er- 
older list is removea . i ms is the least recently used o r 
pjdest entry in the cache. At step 236, remove this entry 


55 


60 
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from its particular previous-next list. At step 237. ha sh 
tfce node id. directo ry file handle, and liame valu es, 
Originally used ahnvp ^ nrina the searcJhjjf step 230: u se 
th g_result of this hashing to index into the directory 
c>cj)e hash table an d find the previous-next lki pointfi^ 
toAt step j STinsert the entry nhi a jned in step 23 3 in 
the previous^next li^ rfctermj rf ,t \ n step 237 and then 
initialize the entry with the node id, directory fuVhan- 
dle, and the name values from set 230 and with the file 
handle returned by step 233. After step 238 the opera- 10 
t ion ends. _ 

uperationTJ), purging entries from the cache in re- 
sponse to a dfs_fs_advise rpc received at the client 
proceeds as follows: 


22 


15 


/• upon receipt of a dfj_ft_advi$e rp C •/ 
for each directory cache entry in the younger- 
older list 


{ 


if entry has the same node id as the node id 
of the dfi_ft_advite rpc*« sender 


step 251 is null, the end of the list has been reached and 
the operation ends. 

Jhe operatio n (3). using the directory cache at the 
client during remote lookup requires searching of the 
directory cache. Such searching proceeds as follows: 


/• Searching starts with a vnode pointer to a 

directory, a node id for the node containing the 
directory, and a name, which is a piece of a 
pathname. 

V 

convert thevngd^ ptr to the directory to a file 
handle: the file handle Is in thej mrrogate 
inode w hich ii Do infrri in hv a member of ih <? 
vnode structure whic h It pointed to by the vnode 
pomterj 

hash int o the directory cache hash table min fi the 

n ode id, directory file handle , anfl nf m*; 
f or each entry on the previous-next list pointed to 
"by t he hash table ele ment indexed by the computed 
hash ~~ - 


remove the entry from the younger-older list: 
insert the entry at the end of the younger-older 

list; 

set the node id value in the entry to a node id 
of zero: 


20 


25 


if node id. directory file handle, and name in 
the entry match those to be searched for 


renim file handle found in the em rv 


a t this point no match was found, so th ere js no 
match in the cache 


return not found 


No real node in an AIX tm system can have a node id 30 
o f zero, so initializing a directory cache entry's node id 
t o zero effectively prev ents any su ccessful m atches with 
the entry durinp sear ches. B y mo ving the entry to th e 
en d of the vounfler-older list, the entry becomes ava il- 
able for reuse when a new value is to be cached. 33 

Referring now to FIG. 18, the detailed flow diagram 
of operation (4) at the client in performing operations 
necessary for the directory caching techniques of this 
invention is shown. The operation depicted in FIG. 18 
is executed each time the client receives a dfs_fs_ad- 40 
vise rpc. 

At step 250, the entry at the beginning of the young- 
er-older list is found. It is pointed to by the pointer 
named youngest in FIG. 20. At step 251, the pointer to 
the next entry in the younger-older list is saved. At the 45 
end of the list this pointer will be null. At step 252, the 
entry is examined. If the node id of the entry is the same 
as the node id of the sender of the dfs_fs_advise rpc 
then proceed with steps 253, 254, 255, and 256, other- 
wise, if the node id is different proceed with step 257. 50 

At step 253, remove the entry from the younger-older 
list. At step 254, remove the entry from the previous- 
next list to which it belongs. At step 255, insert the entry 
at the end of the younger-older list. At step 256, initial- 
ize the node id of the entry to zero. Steps 253, 254, 255, 55 
and 256 effectively remove the entry from the active 
cache elements and make the entry available for reuse. 
Of course, entries that find their way to the end of the 
younger-older list become available for reuse even if 
they are not placed there by this process. Because 60 
entries are moved to the beginning of the younger-older 
list each time they are searched for, only the least re- 
cently used entries make their way to the end of the list. 

At step 257, the pointer saved in step 251 is examined. 
If it is a pointer to an entry the operation proceeds to 65 
step 258. At step 258 this entry becomes the current one 
under examination and the operation continues by re- 
verting to step 251, If at step 257, the pointer saved in 


Referring now to FIG. 23, the detailed flow diagram 
of the search operation necessary for the directory 
caching techniques of this invention is shown. The op- 
eration of FIG. 23 is performed each time the operation 
of FIG. 22, step 230 is performed. 

Thi s operation starts with a node id, a vnode pointer 
t o a directory, ana a name (a parf of a pathname). A t" 
step 270. t he vnode Po jnjgr. to a directory is converte d 
t oa file handle This islione by examining the structu re 
pointed to by the vnode pointer . Th e file handle is in th e 
su rrogate mode which is pointed toby a member of th e 
vnode structure which is pointed to by" the vno de 
pointer. At step 271, the node id, directory file fiand le 
determined in 1 step 2ft), and the name are hashe<T"A t 
s tep 272, this hash value is used to index into the dire c- 
- cac he hash table to obtain a pn»nt?r fn nf fh » 


will be null. 


Lvalue, the value found in the ha sh table 

At step 273, the pointer found in step 272 or in subse- 
quent iterations found in step 275 is examined to deter- 
mine if all entries have been processed. If all entries 
have been processed. The operation ends with an indi- 
cation that no matching cache entry was found. If there 
is at least one moreVntry to process, i.e. the pointer is 
not null, proceed with step 274, 

At step 274. the en try is examined. If its_ norfriH, 
4ircctorv file handle, and name fielfl^atrh «w7g7^ 
s earch request that were used in sTepfrflf, /the operati on 
end, returning the file handle found m the entry llTtJicre 
is-a qmatch the operation proceeds with step ITS. l it 
step ,*7& f a pointer to itne next entry to examine is ob- 
tained from the current entry's field named next. Of 
course, at the end of the list there is no next entry. This 
will be determined in the next step, step 273. 

Files arc frequently renamed and deleted. In the 
method just described, servers would be required to 
send dfs— fs_advise rpes to all clients caching directory 
entries each time one of these common operations oc- 
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cured. This would not allow client nodes to benefit 
from cached information for very long. An enhance- 
ment of the method so far described eliminates this 
problem. 

The enhancement is caching only directory file han- 5 
dies at clients and not non-directory (ordinary) file 
handles. Non-directory files are frequently deleted or 
renamed, but directory files are infrequently deleted or 
renamed. By caching only directory file names at clients 
and sending fs-advise messages to clients only when 10 
server directories are deleted or renamed, clients can 
benefit from their cached information for longer inter- 
vals before invalidation of their cached data happens. 
For example, when following the pathname *Va/b/c M 
to a file, a client would cache "a" with its associated file 15 
handle and "b" with its associated file handle but would 
not cache "c" with its associated file handle. There is 
the negative effect of not being to cache the last compo- 
nent of any pathname that names an ordinary file. 

Notice that the Node Table information at the server 2C 
can be kepi at a finer granularity. An enhancement 
would be to keep in the Node Table at the server a list 
of directories for each client that the client might be 
caching entries from. Then a change to a directory in a 
server would cause dfs_fs_advise rpes to be sent to the 25 
clients thai are possibly caching the changed directory's 
entries, and the dfs_fs_ advise at the client would cause 
only the cache entries for the changed directory to be 
purged, not all of the entries for that server. 

While the invention has been described in terms of a 30 
preferred embodiment in a specific operating system 
environment, those skilled in the art will recognize that 
the invention can be practiced, with modification, in 
other and different operating systems within the spirit 
and scope of the appended claims. 35 
We claim: 

1. A directory caching method for a network of data 
processing systems comprising: 
saving, at a first system, a first unit of directory infor- 
mation about a second system in response to an 40 
inquiry by said first system regarding a directory 
structure of said second system; 
automatically sensing a first notification from said 
second system to said first system in response to a 
subsequent change in said directory structure of 45 
said second system, wherein said first notification 
instructs said first system to erase said first unit of 
directory information; 
detecting an inhibiting condition associated with said 
network of data processing systems, wherein said 50 
inhibiting condition is a saturation of second system 
process resources; and 
automatically sending a second notification from said 
second system to said first system to erase said first 
unit of directory information in response to said 55 
inhibiting condition. 
2. A directory caching method for a network of data 
processing systems comprising: 
saving, at a first system, a first unit of directory infor- 
mation about a second system in response to an 60 
inquiry by said first system regarding a directory 
structure of said second system; 
automatically sending a first notification from said 
second system to said first system in response to a 
subsequent change in said directory structure of 65 
said second system, wherein said first notification 
instructs said first system to erase said first unit of 
directory information; 


,989 

24 

detecting an inhibiting condition associated with said 
network of data processing systems, wherein said 
inhibiting condition is a saturation of process re- 
sources available for the task of automatically send- 
ing said notifications; and 
automatically sending a second notification from said 
second system to said first system to erase said first 
unit of directory information in response to said 
inhibiting condition. 
3. A directory caching method for a network of data 
processing systems comprising: 

saving, at a first system, a first unit of directory infor- 
mation about a second system in response to an 
inquiry by said first system regarding a directory 
structure of said second system; 
automatically sending a first notification from said 
second system to said first system in response to a 
subsequent change in said directory structure of 
said second system, wherein said first notification 
instructs said first system to erase said first unit of 
directory information; 
detecting an inhibiting condition associated with said 
network of data processing systems, wherein said 
inhibiting condition is an unavailability of commu- 
nications resource between said second and first 
systems; and 

automatically sending a second notification from said 
second system to said first system to erase said first 
unit of directory information in response to said 
inhibiting condition. 
4. A directory caching method for a network of data 
processing systems comprising: 
saving, at a first system, a first unit of directory infor- 
mation about a second system in response to an 
inquiry by said first system regarding a directory 
structure of said second system; 
automatically sending a first notification from said 
second system to said first system in response to a 
subsequent change in said directory structure of 
said second system, wherein said first notification 
instructs said first system to erase said first unit of 
directory information; 
detecting an inhibiting condition associated with said 
network of data processing systems, wherein said 
inhibiting condition is a lack of a recent inquiry 
from said first system to said second system regard- 
ing additional directory information; and 
automatically sending a second notification from said 
second system to said first system to erase said first 
unit of directory information in response to said 
inhibiting condition. 
5. A directory caching method for a network of data 
processing systems 6omprising: 
saving, at a first system, a first unit of directory infor- 
mation about a second system in response to an 
inquiry by said first system regarding a directory 
structure of said second system; 
automatically sending a first notification from said 
second system to said first system in response to a 
subsequent change in said directory structure of 
said second system; 
detecting an inhibiting condition associated with said 

network of data processing systems; 
automatically sending a third notification from said 
second system to a third system in response to a 
previous inquiry by said third system of a directory 
structure of said second system and a subsequent 
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change in the directory structure of said second 
system; and 

automatically sending a fourth notification from said 
second system to said first system that said second 
system is unable to send further additional units of 
directory information in response to said condition 
and when said inquiry by said third system was 
more recent than said inquiry by said first system. 

6. A directory caching method for a network of data 
processing systems comprising: 

saving, at a first system, a first unit of directory infor- 
mation about a second system in response to an 
inquiry by said first system regarding a directory 
structure of said second system; 

automatically ending an additional unit of directory 
information from said second system to said first 
system in response to a subsequent change in said 
directory structure of said second system; 

detecting an inhibiting condition associated with said 20 
network of data processing systems, wherein said 
inhibiting condition is a saturation of second system 
process resources; and 

automatically sending a first notification from said 
second system to said first system that said second 
system is unable to send further additional units of 
directory information in response to said inhibiting 
condition. 

7. A directory caching method for a network of dat a 
p rocessing systems comprising: 

saving, at a first system, a first unit of directory infor- 
mation about a second system in response to an 
inquiry by said first system regarding a directory 
structure of said second system; 35 


26 
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30 


automatically sensing an additional unit of directory 
information from said second system to said first 
system in response to a subsequent change in said 
directory structure of said second system; 

detecting an inhibiting condition associated with sai d 

u network oi data processing systems, wherein said 
i nhibiting condition is an unavailability of memory 
at said second system fop ttojrjng s aid additiona l 
Mgjl|of d irectory mformationfor sensing; and 

autoTnWcally sending a first notification from said 
second system to said first system that said second 
system is unable to send further additional units of 
directory information in response to said inhibiting 
condition. 

8, A directory caching method for a network of data 
processing systems comprising: 

saving, at a first system, a first unit of directory infor- 
mation about a second system in response to an 
inquiry by said first system regarding a directory 
structure of said second system; 

automatically sensing an additional unit of directory 
information from said second system to said first 
system in response to a subsequent change in said 
directory structure of said second systems; 

detecting an inhibiting condition associated with said 
network of data processing systems, wherein said 
inhibiting condition is an unavailability of commu- 
nications resources between said second and first 
systems; and 

automatically sending a first notification from said 
second system to said first system that said second 

. system is unable to send further additional units of 
directory information in response to said inhibiting 
condition. 
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UNITED STATES PATENT AND TRADEMARK OFFICE 



PATENT NO. • 5 151 oho 

3,l:> ■ L,989 Page I of 2 

DATED September 29, L992 

'NVENTOR(S) . D. W. Johnson et al 

ccec^si !£r appears ,n ,he above iden,i,ied pa,ent and «« - ^ ■« 

Title page, item (57J, col. 2 

In c he Abstract , line 7> delece ,. director „ __ direcco 
Col. 2, line 35, after "files" insert 
Col. 10, line 10, after "file" insert -system.-; 

Col. 18, line 41. ina e r t Mediately after the boid underscore beginning 
the table -if entry is being removed or renamed-; 
line 38, please delete "if entry"; 
li»e 39, pl.„. ielete .. i8 b . lng ; emoved ^ ^ 
Col. 19. Un. 35. rUum deUt , th , lookup 

some"; 

Une 36, please delete "client; if result is a file handle for a 

directory"; 

Une 39, Mediately after the bold underscore beginning the table 
xnsert -perform the lookup request, requsted by some 

client; — ; 

line 40, mediately following the above insert at line 39, insert 
" lf result is a fi l« handle for a directory-- 
Col. 23, line 43. delece "sensing" and insert -sending-- 
Col. 25, line 16. delete "ending" and insert -sending— 
Col : 26, line 1, delete "sensing" and insert -sending-; 

lin« 9, delete Sensing" and insert -sending-;' 
line 21, delete 'sensing" and insert -sending--; and 
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It is certified that error appears in the above-indentified 
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patent and that said Letters Patent is hereby 


Col. 26. H„e 24, delete "system" and insert -system. 
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Twenty-fourth Day of October, 1995 
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